I suggest that functionality that is needed for payment apps be specified in the payment app specification. We should map out the flow of this first in section 4 of the payment app spec,
then define any additional api requirements in detail further down.

Ian

@ianbjacobs said:

I suggest that functionality that is needed for payment apps be specified in the payment app specification

I disagree, the requirements here will impact what is passed in the request (and this PR is for a change to the PaymentRequest API). That said, the features required here are not required for all payment methods so we need to figure out if they SHOULD be put in the PaymentRequest API or belong only in the Payment Method-specific Data.

@rvm4 said:

Historically we have punted on considerations for these kinds of apps/method

I don't think that is the case. My understanding of the groups position is that we are waiting for more information on what is required so we can decide if this should be put in the PaymentRequest directly or if it is sufficient to use payment method specific data.

This PR suggests that an event be fired when the payment app is selected by the user which would allow the website to trace the payment later but there are a few issues:

1. It returns an ID that is generated by the payment app and we have to date assume that there is no way for the payment app to communicate with the browser after invocation and before returning the final response.
2. It doesn't define how the website would use that id and the idea of "querying the payment app" for the status seems like an unlikely possibility given the current architecture.

There was a lot of interest in solving this at the F2F. Perhaps the best thing to do here is pull together a group of interested parties to first document the possible flows so we can analyze these for possible failure scenarios. Once we have this we can effectively design mitigations.

@adrianhopebailie wrote:

"I disagree, the requirements here will impact what is passed in the request (and this PR is for a change to the PaymentRequest API)"

Right now the payment apps api spec is defined in terms of conformance for user agents. User agents are going to have to change their behavior to implement the spec, including their implementation of the payment request api. For instance, they will need to "hand off control" at a particular place in the payment request API algorithm, then receive it again.

Therefore, I think it's ok to define all payment app-related behavior in the payment app spec, and this COULD involve changes to payment request API.

Ian

Therefore, I think it's ok to define all payment app-related behavior in the payment app spec, and this COULD involve changes to payment request API.

Why would we define changes to another API in the PaymentApps API spec if the API in question is still being defined ESPECIALLY if we haven't even decided if the changes are limited to Payment App-related behaviour?

@adrianhopebailie wrote:

"Why would we define changes to another API in the PaymentApps API spec if the API in question is still being defined ESPECIALLY if we haven't even decided if the changes are limited to Payment App-related behaviour?"

1. I stand behind the idea that third party payment apps is a layer that we are adding above the payment request API, and that payment request API does not currently speak about third party payment apps at all, nor does it need to.
2. I agree with you that if some behavior is not about integration of payment apps into the ecosystem, then it's worth considering modifications to the payment request API. I am fine to continue the discussion about the desired behavior without deciding yet where the bits go. But if, in the end, this is about third party payment app integration, then I think it can go in the payment app api spec at this stage.

Ian

So this PR was meant to spur discussion. It is far from complete. It is apparent that there is nowhere near consensus, so I would second creating a dedicated group to tackle this issue and come up with a variety of alternatives.

@rvm4 that was the general feeling on yesterday's call.

We're going to start the discussion via the list or some issues and then can either raise on one of our weekly calls or have a dedicated call to discuss.

It seems like the details for checking push payment status would be specific to the payment method. That doesn't mean there can't be some generalized mechanism for communicating those details, but it may be better as a URL to the payee's site that the payment app can contact or something to that effect. I think that would be more resilient. I'm also not keen on revealing payment app information to the payee through the Payment Request API.

We are closing as obsolete in favor of transaction-id.